home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄24⁄90 / 1806-Multiple Inheritance-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.5 KB  |  84 lines  |  [TEXT/GEOL]
  1. Item    6435527                         24-Aug-90        05:32PDT
  2.  
  3. From:   POWERUP.ENG                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Multiple Inheritance Ques
  8.  
  9. Attn:   MacApp.Tech$
  10. SentBy: James Plamondon
  11. Date   8/23/90
  12. Subject    Multiple Inheritance Questi
  13. From   James Plamondon
  14. To   MacApp.Tech$
  15.  
  16. Subject:   Multiple Inheritance Question
  17. Gentlepersons,
  18.  
  19. I've been asked more than once for an example of a situation in which multiple
  20. inheritance is really useful, rather than being a means of avoiding thoughtful
  21. design.  I think I've come up with one, and I'd like to hear the comments of
  22. anyone interested in responding.
  23.  
  24. Consider a application which allows the user to play draw poker against the
  25. computer.
  26.  
  27. Each card can be in any one of four states at any given time:
  28. • neither player can see it at all
  29. • both players can see its back
  30. • both players can see its face
  31. • one player can see only its back, while the other can see only its face
  32.  
  33. Let's assume that both players are trying to cheat, by marking the backs of
  34. some of the cards.  Then, viewing the back of the card might give the viewer
  35. some valuable information about the card (although not as much as could be
  36. gained by viewing its face).  Each player would have a list of references to
  37. the cards in her hand, and to those in her opponent's hand.  Each player would
  38. look at only the faces of her own cards, and only the backs of her opponent's
  39. cards, while both could examine the back of the card on the top of the deck.
  40.  
  41. The question is — how to represent a card?  One way to represent the cards
  42. would be to have a single class, TCard, which would contain a description of
  43. both a card's front and its back.
  44.  
  45. But — what would stop the program from cheating even more, and looking at the
  46. faces of its opponent's cards?  A TCard is a TCard is a TCard — and if the
  47. computer can access the face data of its own TCards, then it can access the
  48. face data of its opponent's TCards, too.  Declaring the face data members
  49. "private" wouldn't help — then the computer couldn't see the faces of its own
  50. cards, either.
  51.  
  52. If, faced with this problem, we chose to redesign the program so that each
  53. card would be represented by two different objects — its back and its face —
  54. then we would have introduced a significant source of potential errors:  the
  55. two objects could get disassociated, so that the back of one card would be
  56. associated with the face of another.
  57.  
  58. Here's my proposed solution.  Use two classes, TCardFace and TCardBack, to
  59. describe the face and back of a card, respectively.  Then, have a third class,
  60. TCard, inherit from both, allowing the complete description of a card within a
  61. single TCard object.
  62.  
  63. Each card in the game would be described by a single TCard object.  Each
  64. player's own cards would be kept in a list of objects of type TCardFace, while
  65. her list of her opponents cards would be refered to as objects of type
  66. TCardBack.  Thus, each player would have access to only that portion of the
  67. card's representation that was appropriate, while still retaining the
  68. advantages of having each card be represented by a single object.
  69.  
  70. Of course, for every defense, there's an offense:  a player could always cast
  71. the reference to  the opponent's card to a TCard, and then cheat to her
  72. heart's content.
  73.  
  74. And so I ask — is this an elegant solution to a thorny problem, or just
  75. another example of the kind of weird, convoluted kludge for which I've become
  76. infamous?
  77.  
  78. Looking forward to your responses, I remain
  79.  
  80. Yours,
  81.  
  82. James Plamondon
  83.  
  84.